Add RFC: Streamline startups workflow #285
Conversation
| * Use PostHog-the-app to filter by whether a user has clicked that or not, and show a banner that says “🎉 You’re eligible for the startup plan! Get started here.” | ||
| * Build a new page on the app: /project/###/startups | ||
| * Host the completion steps of the form here. | ||
| * * All we need to ask for is what we don't already know. I think that's just "How much in total funding have you raised (USD)" and "The date that your company was incorporated." |
There was a problem hiding this comment.
I guess to make things easier we can automatically apply the credits immediately, but then asynchronously check whether they're actually allowed to get them and reverse if not?
There was a problem hiding this comment.
+1 - this credits won't be used for at least 30 days so we have time to roll back from bad actors.
| ## What can we do about it? | ||
| - **Steps 2 and 3,** above, should not have to happen. (We already have a record of *most* of the info, because a PostHog account is required to apply.) | ||
| - I think this means the actual **sign-up form should be gated**, accessible from the app itself — requiring a user to be in a logged-in state to submit. | ||
| - I think the system should **auto-filter applications:** if they are not eligible, do not apply the credits. *(We can write nice rejections: “Did we get that wrong? Contact Scott if you think there’s been a mistake. We like being generous, but sometimes the our auto-bots are fierce defenders of the realm.”)* |
There was a problem hiding this comment.
Love this language as a fallback option, btw
There was a problem hiding this comment.
Agree this is a great idea - it'll fit more naturally into the flow. We just need to figure out when to surface it.
@joshsny might have some ideas.
|
|
||
| ## What can we do about it? | ||
| - **Steps 2 and 3,** above, should not have to happen. (We already have a record of *most* of the info, because a PostHog account is required to apply.) | ||
| - I think this means the actual **sign-up form should be gated**, accessible from the app itself — requiring a user to be in a logged-in state to submit. |
There was a problem hiding this comment.
This is actually a brilliant solution if we can find a way to make it work within the app.
Do you have an idea on where it would sit? Billing page would seem a good choice, to me. We could also use this as an opportunity to implement the billing badges I proposed a while ago and which I think @raquelmsmith and @patricio-posthog have been hoping to ship this quarter too.
There was a problem hiding this comment.
We'd definitely want to keep the existing /startups page on PostHog.com, right? We can just have the 'Apply now' button direct to the relevant area of the app and cut the form.
There was a problem hiding this comment.
@joethreepwood Thank you! Your billing badges idea sounds like a brilliant way to do this. It would surface the available tier at just the right spot.
(This comes with the assumption that each of those plan tier badges would link to their own page to go into more detail on what it's involved?)
Yep, for sure we have to keep the /startups page on PostHog.com. As you say, we would just need to re-think the CTA.
| * I get a little lost in the plumbing after this and am asking for support thinking through the path. | ||
|
|
||
| ## Three other considerations: | ||
| * **Solving for the YC program too:** It needs similar care, as the form at [yc-onboarding](https://posthog.com/yc-onboarding) generates all the same challenges. It has the same issue of manual back and forth that causes too much friction. The same issues apply, and I think a similar solution can be considered. |
There was a problem hiding this comment.
The slight difference here is that we need to check that the person is in the YC program by their Bookface access, and we really want them to hit 'Using this deal' on our Bookface page. However, maybe we can have that be part of a white-glove service handled by the proposed YC Implementation hire.
There was a problem hiding this comment.
I agree I don't know if doing this for YC is the best path because then we wouldn't be able to confirm their batch and if they are in YC.
We could have a custom url that is linked from the deal which renders a version of the form just for YC? Downside is they may not always go through the YC deal link if it's accessible elsewhere. How can we demonstrate you get more via the deal then just normal startups?
| ## Three other considerations: | ||
| * **Solving for the YC program too:** It needs similar care, as the form at [yc-onboarding](https://posthog.com/yc-onboarding) generates all the same challenges. It has the same issue of manual back and forth that causes too much friction. The same issues apply, and I think a similar solution can be considered. | ||
| * **Solving for other deals:** Besides the YC deal, PostHog will continue to set up other deals with other accelerators / VC programs. It would be smart to think of this as a workflow we can replicate and edit the minor details for emerging deals. | ||
| * **Solving for internal reporting:** Because so many systems are talking to one another here, there is a lot of manual reporting between Zapier tables, Stripe data, Salesforce, Vitally and PostHog to get a source-of-truth view of how our startups programs and YC adoption is doing. I think if we can find ways to let the systems do the talking, we should hopefully result naturally in cleaner data, but if we can undertake this job with this in mind, we'd be even better off. |
There was a problem hiding this comment.
@minekansu I think you're the expert of the Zap and Vitally side of things, so just tagging you in case you have Thoughts
There was a problem hiding this comment.
If the application info will be in posthog or stripe then we can sync vitally and salesforce directly without using zapier which would make it easier to maintain 💯 instead of zaps we can just use posthog destinations or if this info will be in stripe metadata we can sync from there
a couple other things that came to mind:
- we probably need a step ensuring applicants add a credit card before approval otherwise we cannot add credits, should this be a blocking step?
- right now we check clearbit data for each applicant to verify their funding raised and incorporation date. If their clearbit data does not meet our criteria we send an automatic follow-up even if the information they entered in the form does meet our criteria. Clearbit data isn’t always available but if a company appears in clearbit it’s usually a signal that they might be a larger company, probably helpful to have this data somewhere for the manual review process.
There was a problem hiding this comment.
I spent some time with @minekansu today.
Overall I think this is doable but a few things we need to get answered first.
- How do we apply custom credits for partners automatically (the extra $5k)?
- Where do we send the data after approval so it can be verified? Do we enrich it with clearbit?
- How do we verify YC companies? And make sure they are clicking from the deal?
Side note:
- we need to update the bookface deal, some of the language it out of data (i.e. A/B testing), there are missing products (i.e. Errors and LLM Oberservability)
- as discussed here: https://posthog.slack.com/archives/C075D3C5HST/p1730305630450429, we should just remove the $25k deal for YC startups and do $50 for all of them to simplify things. We need to update the Bookface deal and the YC landing page.
| ## Proposed flow: | ||
| * Remove the actual application form fields (just the form fields) from [the page](https://posthog.com/startups/apply) | ||
| * Replace it with a call-to-action to “Sign in or sign up to apply” | ||
| * Use PostHog-the-app to filter by whether a user has clicked that or not, and show a banner that says “🎉 You’re eligible for the startup plan! Get started here.” |
There was a problem hiding this comment.
We don't really have this data available in app so maybe it's available to everyone somewhere on the billing page?
| * Build a new page on the app: /project/###/startups | ||
| * Host the completion steps of the form here. | ||
| * * All we need to ask for is what we don't already know. I think that's just "How much in total funding have you raised (USD)" and "The date that your company was incorporated." | ||
| * I get a little lost in the plumbing after this and am asking for support thinking through the path. |
There was a problem hiding this comment.
Assuming we submitted for form directly here and they met the requirements, we could do the things that the current "Approve" button in Zapier does
- apply credits in stripe
- apply metadata in stripe
- send an email
Areas that are trickier
- where do we track this so Scott or Kevan can review it for false positives?
- this is sorta standardized so we wouldn't know whether or not to at the extra $5k for our partners
- how can we reply on the submitted data? will Scott/Kevan still manually review it all? Or do we enrich it someone and check against that data?
There was a problem hiding this comment.
Zach, loving your thoughts here, and I've booked time for us to chat tomorrow.
On reviewing applications
I have recently introduced a new question on the automated email that asks people to write a bit of a blurb on what they are building, and provide their landing page URL. This is because our partners at Digital Ocean were detecting some cases (not many) of security/fraud risk, and we wanted to make sure we had good players. But it also does something valuable for PostHog: encourages applicants to use the human touch (as we do in our job applications) to show they are serious, real, they want this, and there is at least a SLIGHT bar. Not a high one.
All that to say, keeping the manual review might not be a terrible idea. But removing the steps it takes for us to approve (zapier > vitally > stripe id > zapier > click button) -- that seems really nice.
$5k for our partners
I actually haven't come across this in my workflows. Who gets the extra $5k?
There was a problem hiding this comment.
$5k for our partners
I actually haven't come across this in my workflows. Who gets the extra $5k?
We can offer an extra $5k through the Zapier for people who refer other startups. We can arguably retire this though, as it's only rarely claimed.
| * I get a little lost in the plumbing after this and am asking for support thinking through the path. | ||
|
|
||
| ## Three other considerations: | ||
| * **Solving for the YC program too:** It needs similar care, as the form at [yc-onboarding](https://posthog.com/yc-onboarding) generates all the same challenges. It has the same issue of manual back and forth that causes too much friction. The same issues apply, and I think a similar solution can be considered. |
There was a problem hiding this comment.
I agree I don't know if doing this for YC is the best path because then we wouldn't be able to confirm their batch and if they are in YC.
We could have a custom url that is linked from the deal which renders a version of the form just for YC? Downside is they may not always go through the YC deal link if it's accessible elsewhere. How can we demonstrate you get more via the deal then just normal startups?
(I'm less familiar with the extra $5k deal, but would like to learn what that's about)
Great question; I'm open. A zapier table, spreadsheet, internal dashboard, email digest...if the steps of approval are simplified, the job of reviewing becomes a little easier. (I totally don't mind some aspect of manual review, especially with the new "application-style" question I mentioned in my other note.)
A custom URL could work here.
Awesome; I have access to edit that directly now. Let's chat about what we want to see. |
Suggestions for improving the way we manage incoming startup applications